The present invention relates to a sending node of a transaction server in a network, and more specifically, to balancing work of tasks at a sending node of a transaction server in a network.
An on-line transaction processing (OLTP) monitor, such as CICS transaction server for z/OS (CICS and z/OS are trademarks of International Business Machines Corporation), contains a set of interfaces that it uses to communicate with other nodes in the networks that it wishes to interact with. Once a connection is established tasks, which are instances of transactions, running under the monitor's control can then send and receive messages using these interfaces. The size of these messages can potentially be very large and those that are large may be broken into smaller chunks that are transmitted separately and then recombined by the target node that they are delivered to.
In a busy system, many concurrent tasks may be running that wish to make use of the same network connection. However messages can only be transmitted one at a time, and so tasks will queue while waiting for their message to be transmitted. If the message size is very large then this can cause significant delays for other tasks in the queue.
To address this, many network protocols support a mechanism called pacing, which is intended to limit the number of message chunks that are sent before a task gives up control of the connection to allow others to make use of it. This is typically implemented using a pacing indicator which is added to a message chunk to indicate that no further chunks will be transmitted until a reply is received. This causes the task to become suspended until the partner node returns a pacing response message, after which it can re-join the queue of tasks waiting to use the connection and then transmit the next set of message chunks.
The maximum number of chunks that a task can transmit is defined by the message protocol that is being used. Some protocols used by transaction servers to communicate over a transmission control protocol/Internet protocol (TCP/IP) network sets a limit of four chunks before a task is placed into a pacing wait state. Such protocols then insert a pacing response indicator into the last chunk that is being transmitted, allowing the receiving node to recognize when it is being asked to return a pacing response message. This maximum number of chunks value is fixed for all tasks using a common network protocol and under some circumstances this can adversely affect the efficiency of the overall workload using a particular connection.